home *** CD-ROM | disk | FTP | other *** search
/ Sprite 1984 - 1993 / Sprite 1984 - 1993.iso / admin / bugs / bugs.archive.old < prev    next >
Encoding:
Text File  |  1990-12-11  |  14.9 KB  |  379 lines
  1.  
  2. 1.  (zorn)
  3.     Sometimes tonkawa goes into `slow mode' and takes a very long time
  4.     to respond over rlogin connections.  Paul has noticed this and said
  5.     that it had something to do with tonkawa completely losing its host
  6.     tables.  Paul's solution is to reboot tonkawa.  Perhaps Mendel is
  7.     already aware of the problem.
  8.  
  9. 2.  (zorn)
  10.     When I rlogin to sage, I get the following message:
  11.  
  12.     Sprite SPRITE VERSION 1.0 (Brent sun3) (16 Dec 88 15:29:48)
  13.  
  14.         Welcome to Sprite
  15.  
  16.     *** compat: Cannot decode user status value ffffffff
  17.     sage 1; 
  18.  
  19. 3.  (zorn)
  20.     stty on Sprite doesn't have the rows and columns attributes, which
  21.     can be used to change how big vi thinks your window is.
  22.  
  23. 5.  (zorn)
  24.     If a program creates a big file and uses up all the disk space on
  25.     sioux (Sun2 fileserver for SPUR and tonkawa), sioux hangs and even if
  26.     the process creating the file is deleted, you can't remove the file
  27.     using up all the space, and the only solution I know is to reboot
  28.     sioux, tonkawa, and spur.
  29.  
  30. 10. (zorn)
  31.     I often forget that I've got processes in the DEBUG state and
  32.     since their executables are still in use, even when I delete the
  33.     executable (like scl, 3 megabytes worth), the file space isn't
  34.     reclaimed because a DEBUG process still has a pointer to it.  Could
  35.     you give me a command that will guarantee to kill all my processes in
  36.     the DEBUG state that I'm not currently debugging?
  37.  
  38. 11. (fred)
  39.     Missing fonts for TeX.
  40.  
  41. 16. (rab)
  42.     Excessive mallocs at user level will crash sprite.
  43.  
  44. 17. (jhh)
  45.     ProcessLine called Fs_NotifyReader passing it nil as a data pointer, causing
  46.     a bus error. eventNotifyToken is nil for some reason. This happened after
  47.     the following sequence of events : try to print something on sloth, lpd is
  48.     started, THEN we plug in the printer. Sloth crashed right after this, which
  49.     leads me to believe there is a connection here.
  50.  
  51. 18. (mendel)
  52.     Kernel uses malloc'ed memory after free'ing it.
  53.  
  54. 20. (mendel)
  55.     Readdir doesn't fix byte order problems properly for spur.
  56.     Need to add system calls for readdir and statdir.
  57.  
  58. 21. (mgbaker)
  59.     When I link a kernel in /sprite/src/kernel/mgbaker, the linker (/usr/bin/ld)
  60.     on the sun4 says "write output error:  l.aXXXXXX not found."
  61.  
  62. 22. (ouster)
  63.     It appears to me that there's a repeatable bug whereby pseudo-devices
  64.     don't close down correctly.  If I start X running, then use L1-K to
  65.     kill X, I'm left with a bunch of csh processes in RWAIT state (one for
  66.     every Tx window that was open).  I tried to "kill -DEBUG" them to see
  67.     where they are, but the processes won't enter the debugger.  I suspect
  68.     that this is because they are waiting on their stdin pseudo-device.
  69.  
  70. 23. (douglis)
  71.     If I rlogin to sprite, start vi, use ^Z to suspend it, and then try
  72.     to resume, I get thrown back into the shell with my terminal in raw
  73.     mode and my vi nowhere to be seen.
  74.  
  75. 24. (ouster)
  76.     The reason vi doesn't know about the window size is because our terminal
  77.     driver doesn't (yet) support the TIOCSWINSZ and TIOCGWINSZ ioctls.
  78.  
  79. 25.
  80.     File servers run out of memory.
  81.  
  82.  
  83. 26. (fwo)
  84.     I'm getting another NFS problem while moving data to rosemary:
  85.         NFSPROC_WRITE: RPC: Unable to send; errno = socket is not connected
  86.  
  87.     The result is that tar cannot restore the file:
  88.     tar: Tried to write 4096 bytes to file, could only write -1:
  89.     my.filename: invalid argument
  90.  
  91. 27. (douglis)
  92.     stat of /dev/console
  93.     This doesn't seem to work.  I thought it did at first, and I modified
  94.     loadavg to use this rather than relying on the internal kernel
  95.     variable.  However, it didn't show the time getting updated, and
  96.     statting /dev/console just showed it not getting a new time.  It's
  97.     said 19:32:05 (read: "18:32:05") for the past couple of minutes.
  98.  
  99. 28. (douglis)
  100.     bug: suspending a migrated process locks out system
  101.     That is, if one suspends a pmake running remotely, that remote
  102.     host is marked forever as unavailable for other migrations.
  103.     This is just Yet Another Reason for a more sophisticated system
  104.     with handlers for various events, including signals to migrated
  105.     processes. In the meantime, I will change the daemon that
  106.     watches migrated processes and make sure it only believes the
  107.     "in use" bit on its own machine if there is a foreign *runnable*
  108.     process.  Of course, this means if someone suspends and
  109.     immediately resumes a remote job, then the host could get
  110.     flagged as available ang get loaded down by a second job, but
  111.     thems the breaks.
  112.  
  113. 29. (douglis)
  114.     behavior on failed page write:
  115.     We discussed recently how the behavior had been changed to kill
  116.     processes rather than wait for space to free up. Is this correct?
  117.     In general, I'd prefer to wait than to have my entire window
  118.     system die because we run out of swap space!
  119.  
  120. 30. (douglis)
  121.     The kiss of death: migrate a process onto a machine when the disk
  122.     space fills and the page-out fails.  Paprika lost its window system
  123.     because a pageout failed when I was starting a make, and at the same
  124.     time, fenugreek died with a watchdog reset.  I now just noticed that
  125.     several other hosts died at the same time and are not reachable via
  126.     kmsg, implying they may have hit watchdog resets too.
  127.     Looks like I have to make that migration code more robust.  In the
  128.     meantime, this is another case for keeping /a less than full! :)
  129.  
  130. 31. (douglis)
  131.     bug: pmake debug children, define syntax
  132.  
  133.     There seems to be a problem with pmake, compared to make, that kept
  134.     the following construct in local.mk from working:
  135.  
  136.     CFLAGS += -DUSERMEM=`cat USERMEM`
  137.  
  138.     When I tried to run mkmf on compress, which uses this construct, I hit some 
  139.     error messages followed by an endless loop with the same process being
  140.     continued and going into the debugger repeatedly:
  141.  
  142.  
  143. 32. (ouster)
  144.     Bug: finger/rup database corrupted
  145.     The finger/rup database seems to have mangled itself over the weekend.
  146.     For example, "rup" says that oregano is down, but I can rlogin to it
  147.     and its running Sprite.  Also, "finger" says that almost no-one is
  148.     logged in... although I can't confirm that this is wrong, it looks
  149.     suspicious.
  150.  
  151. 33. (mgbaker)
  152.      another funny nfs thing
  153.      When I'm working in the sprite hierarchy, but on rosemary,
  154.      and I do a "ci -l" of some files to rcs, weird things happen.
  155.      I can continue to edit the files on sprite, and everything is
  156.      happy, but from that point on, none of the changes will be
  157.      reflected in the same files when I view them from rosemary.
  158.      The dates don't change and the data doesn't change.  Also,
  159.      the number of links for them, listed by "ls", is 0.  It should
  160.      be 1.  (This is all easily curable by removing the files from
  161.      rosemary and rewriting them again on sprite.)
  162.  
  163. 34. (ouster)
  164.     Bug: ipServer crash
  165.     My ipServer died shortly after the Mint crash today (but I suspect that
  166.     the two are only marginally-related).
  167.  
  168. 35. (douglis)
  169.     things would be much easier if we had a unix-ish syslog
  170.     approach, in which syslog messages are stored in a regular file and
  171.     cycled through on a daily or weekly basis to keep from storing old
  172.     messages too long.  With syslog going only to the console, or some
  173.     other process reading it, there's no way for someone else to see the
  174.     messages.
  175.  
  176. 36. (jhh)
  177.      ditroff problem?
  178.      I get the following message when I try to print a man page.
  179.      ditroff -Pcad -man fstrash.man
  180.      troff: Can't open /sprite/lib/ditroff/devpsc/c.out
  181.      There is a file /sprite/lib/ditroff/devpsc/C.out
  182.      did something change recently?
  183.  
  184. 37. (brent)
  185.     pseudo-device access/modify times
  186.     Garth pointed out an interesting behavior of the modify time
  187.     of a tx window.  Go to an idle tx window and do an ls -l of
  188.     its corresponding tx pseudo-device.  The modify time won't
  189.     reflect your typing of the ls command.  If you repeat the ls
  190.     then the modify time will be current, reflecting the generation
  191.     of the prompt for the second ls.  If you do ls -lu to get the
  192.     access time, it will be current.  Now, as a final twist, if
  193.     you use the stat program you always get the correct dates.
  194.     That is (apparently) because ls uses stat(filename), while
  195.     stat uses fstat(openFile).  Frankly, that these are different
  196.     is still a suprise to me.  I'll mull this one over, but may
  197.     not change anything.
  198.  
  199. 38. (mendel)
  200.     fstat() doesn't get correct modify time
  201.     If a process has a file open and another process  modifies the file the 
  202.     modify time as return by the fstat() library routine is not updated.
  203.     The stat() routine does return the correct modify time.
  204.     This is why the unfsd has been working so poorly on sprite.
  205.  
  206. 39. (gibson)
  207.     looks to me that whenever I invoke enscript with more than one
  208.     file on the command line, it says it can't open the second file
  209.     and dies.
  210.  
  211. 40. (ouster)
  212.     RPC/sendmail messages
  213.     I just noticed the following messages in my syslog window:
  214.     RpcScatter: rpc 7 param size + off (4 + 0) > (0)
  215.     <19>Jan 26 11:22:30 sendmail[91b3d]: tung@ibm.com... reply: read error
  216.     <19>Jan 26 11:29:03 sendmail[41b3b]: mogul@decwrl.dec.com reply: read error
  217.     Does anyone know if any of these messages is cause for concern?  Do
  218.     the sendmail messages mean that mail was lost?
  219.  
  220.  
  221. 41.  (brent)
  222.     bug: var val
  223.  
  224.     When Mike implemented the system call for vmcmd he used a macro
  225.     trick that doesn't work with gcc, so he generates printfs when
  226.     you change VM constants that say "var val is 1200", etc.  There
  227.     are two bugs.  The first is that the kernel shouldn't generate
  228.     these print statements.  The user program that changes the
  229.     value should.  The second bug is the "var val" macro bug, which
  230.     won't need to be fixed if the system call is changed to return
  231.     the old variable value.  The Fs_Command system call is set up
  232.     to return the old value of a variable being changed, but the
  233.     Vm_Command system call is not.  Perhaps a third bug is that
  234.     these two system calls are distinct, and there is even another
  235.     cesspool-call, er, system call, called Sys_Stat.
  236.  
  237. 42. (mgbaker)
  238.      mkmf becoming a pain
  239.  
  240.      Is there a way to ask mkmf only to redo things for a particular
  241.      machine? It does not scale well as we increase the number of
  242.      machines we have ported to.  It can take several minutes to
  243.      add one file to one machine's subdirectory.
  244.  
  245. 42. (hilfingr)
  246.     File rot on tonkawa still
  247.  
  248.     FYI:  The file rot problem on tonkawa is still with us.  It struck
  249.     within the last few days (I believe).
  250.  
  251. 43. (jhh)
  252.     Xsprite bug
  253.  
  254.     Xsprite went into the debugger on me. I poked around a bit and
  255.     found it had segmentation violation in the function PdevReadClient,
  256.     file os/pdev.c line 825. I don't know what a real client
  257.     structure is supposed to look like, but a streamID > 327000
  258.     looks bad to me. I think Dispatch somehow tried to do a read
  259.     on a nonexistent client.
  260.  
  261. 44. (Gibson)
  262.     cp -p problem
  263.  
  264.     I tried cp -p /nfs_file_1 /nfs_file_2 but /nfs_file_1 was
  265.     read_only to me so the result was a /nfs_file_2 file of zero
  266.     length and a permission denied error message
  267.  
  268.     it seems that the read only protection is done first
  269.     but then the copy writes fail
  270.  
  271.     i checked on UNIX and this does not happen (different cp command?)
  272.  
  273. 45. (gibson)
  274.      nfs and symbolic links
  275.  
  276.      running under sprite, i make a symbolic link through nfs to a unix
  277.      filesystem - but i can't read it or follow it
  278.  
  279.      the problem is different symbolic link formats under unix and sprite
  280.      sprite adds a null to the end of the link file (according to brent)
  281.      so unix is unhappy when nfs tells it to access the link
  282.  
  283.      brent knows about this and may do something about it
  284.  
  285. There are actually two problems.  The first is the one about
  286. different link formats.  I'll be changing Sprite servers to
  287. be UNIX-like sometime soon. The other problem was that you
  288. couldn't readlink() a symbolic link via nfsmount, regarless
  289. of who created the link.  I've fixed this bug.
  290.     brent
  291.  
  292. 46.  (mgbaker)
  293.      Vm tracing bug?
  294.  
  295.      In going over the assembly routines for the virtual memory module,
  296.      it appears to me that the VmMachTracePMEG routine is buggy on the
  297.      sun2's and 3's.  It should trace a page if the page is resident
  298.      and also is either referenced or modified.  But it traces it in
  299.      some cases even if it isn't resident.  So unless the modified and
  300.      referenced bits are cleared when the page isn't resident, this
  301.      routine will give wrong numbers.  Is there anyone out there who
  302.      depended on this routine?  If so, I'll check how the referenced
  303.      and modified bits are cleared to see if things were okay or not...
  304.  
  305. 47.  (douglis)
  306.     bug: recovery consistency crashed network
  307.  
  308.     We had to reboot the world because mint got itself a bit confused.  I
  309.     think Brent was aware of this when he tried to continue it earlier
  310.     after "client N not last writer M" messages kept coming out (each one
  311.     hitting a breakpoint).  The problem is, after mint rebooted it hit the
  312.     same error, each time with a different client.  My brute-force
  313.     solution was to reboot the clients so they wouldn't try to force
  314.     anything on mint that it couldn't handle.
  315.  
  316.     Brent, the lineprinter output in the machine room contains some other
  317.     interesting messages about stale files & such that I hadn't seen
  318.     before.  Maybe they're relevant.
  319.  
  320. 48.  (douglis)
  321.     bug: scsi tape error
  322.  
  323.     The thing we hit last time, and which we still hit, is as follows:
  324.  
  325.     SCSITape, 10 sense bytes => Unknown sense size
  326.     DevSCSITapeError: Unknown tape drive typeSCSI-0: Sense error (7-0) at <600>
  327.  
  328.     this is kernel (JohnH sun2) 1/15/89
  329.  
  330. 49.  (douglis)
  331.     bug: lpd doesn't compile
  332.  
  333.     I did a mkmf so I could install a sun2 version and not use a year-old
  334.     version on the sun2s at boottime, with named pipes.
  335.  
  336.     I hit a compiler error in lpd.c, both for sun2s and then again for
  337.     sun3s.
  338.  
  339. 50. (jhh)
  340.     migration bug
  341.  
  342.     I tried to kill a migrated process (a ps on the process gave
  343.     me one of those "couldn't read segment info..." messages) and
  344.     it put thyme into the debugger.  The process control block was
  345.     garbage.
  346.  
  347. 51.  (mendel)
  348.     sendmail bug
  349.  
  350.     I can't send mail from my Sprite account.  Sendmail goes into a loop
  351.     forking itself and exiting.  
  352.  
  353. 52.  (jhh)
  354.      bug
  355.  
  356.  
  357.     When I try to rcp my kernel to ginger I get the following error:
  358.  
  359.     Pdev_Write, no return amtWritten (/hosts/sage.Berkeley.EDU/netTCP)
  360.     RequestResponse request too large
  361.  
  362.     If I do the rcp from ginger everything works.
  363.  
  364. 53.  (douglis)
  365.      fs/migration bug
  366.  
  367.     I was running a compile, which hung.  I noticed in my syslog:
  368.  
  369.     Fs_RpcWrite, stale handle <0,192> client 5
  370.     2/16/89 10:56:32 basil (5) starting recovery
  371.  
  372.     This recovery never finished.  Turns out in addition, I had
  373.     only one process in the migrated state but at least one process
  374.     that was running on basil but on paprika was in the NEW state.
  375.     Signalling the NEW process had no effect, and signalling the
  376.     process using its id on basil caused the rpc to hang.
  377.  
  378.  
  379.